Over the last two decades, the Internet has developed from a communication tool used mostly by academicians and researchers into a multi-billion dollar commercial media that has been interwoven into virtually every aspect of our lives. As the World Wide Web (WWW) grew to become the dominant Internet access tool, individuals and companies generally began to build Web pages for public access. In the beginning of this Internet revolution, most Web items were created using hypertext mark-up language (HTML). HTML is a text-based language that is used to format the display of information and provide linking between different pieces of information in such a manner that any person running an HTML-compliant Web browser will generally be capable of seeing the information presented as designed by the Web page creator.
Early developers would typically write HTML files using simple text editors and then place those HTML files onto Web servers. The Web servers would then generally be used to serve up the HTML files to any accessing applications, called clients. Once the client receives the HTML file, a Web browser on the client would typically access those pages and display them according to the format coded by the HTML. The basic extent of the interaction in this format then was that a user may typically enter a uniform resource locator (URL) into their Web browser, the request for the document corresponding to that URL would generally be sent across the Internet and received by a Web server. The Web server then usually determines what document the user wants and serves up that document by sending the HTML file back across the Internet to the client's Web browser. The Web browser then takes that document and renders it in a pretty way, so you may have formatting around your text, such as bold, colors, backgrounds, and the like.
The static nature of pure HTML established a limit to the interactivity and functionality available to Internet applications. In response to the growing demand for more Web functionality, dynamic applications began to evolve. Dynamic applications are typically able to merge static HTML with dynamic data and logic processing in the files served to accessing clients. Such dynamic applications generally led to the capability of developing business oriented applications. Business applications typically need more extensive interaction and processing of data. Such data is typically stored or processed in the business' back-end systems (i.e., the systems and computers controlled by the business and that hold the business' databases or files). Users connecting to a typical early business application were able to browse through on-line catalogs and buy the vendor's product directly from the Website. This process generally requires combining the staticness of HTML, for viewing the documents on the Website, with the processing of data and information stored in the back-end systems necessary for generating the HTML documents. Thus, the dynamic applications evolved into a system in which HTML Web pages are built as the application is executed using the data that exists in the business back-end systems.
Dynamic applications began by generally using common gateway interface (CGI) programs, which essentially allow a program to be written that runs in the context of the host Web server. The program would typically do nothing but possibly generate Web pages for the dynamic application. As dynamic applications grew in number and complexity, the amount of program and function logic hosted on the Web server led to the development of application servers, the next generation of Web functionality. An application server's main focus is to host all of the program and/or function logic that will be executed and interact with the business' back-end systems. In essence, therefore, the application server generally acts as middle-ware between the Web browser and the back-end systems.
With the continued development of dynamic applications and application servers, there typically became a much higher learning curve for developers to build these applications. Developers not only are required to understand the basic construction of Web pages using HTML, but are also required to understand the connectivity, interaction, and processing structures and requirements for working with the back-end systems. In a typical case using this newer architecture, a Web browser typically requests a Web page with a dynamic application, but now, instead of the Web page being served up directly by a Web server, an application server receives and processes the incoming request, and then executes a component program or application that interacts with the back-end systems to execute the functionality of the dynamic application. The application server then generates the HTML necessary to display the results of the dynamic application. The browser renders the HTML as before. So to the user on the front-end, not much has changed. However, the complexity on the application server and in the back-end has substantially increased.
Initially, dynamic applications are programmed using standard programming languages, such as C++ and C. However, the training and experience generally required for this standard programming prompted individuals and companies to develop higher-level scripting languages to “script” the functional elements of the dynamic applications. The main goal of scripting languages is to provide a more intuitive, less training-intensive means for full program functionality development. One such scripting language which grew out of the dynamic application evolution is MACROMEDIA'S COLDFUSION™. COLDFUSION™ became the first true script-based application server that brought the world of dynamic applications to the typical Web developer who did not have formal programming training. COLDFUSION™ and it's scripting language, COLDFUSION MARK-UP LANGUAGE™ (CFML™) allow Web developers, familiar with typical tag-based mark-up languages, such as HTML, to more easily script/program the dynamic integration of Web accessibility with the data-intensive back-end systems. The other primary scripting languages that either have been used to program dynamic applications or were specifically developed for dynamic applications include Practical Extraction Report Language (PERL), developed by Larry Wall, and MICROSOFT'S ACTIVE SERVER PAGES (ASP™).
One unfortunate result of bringing the ability to create complex dynamic applications to Web developers with little or no formal training in programming is that the applications that began to surface really had very little structure to the way they were created. Files are typically placed in ad hoc locations making it very difficult to manage and/or understanding how the application fits together and operates. Developers generally place the functional logic in any random directory, which impairs the ability to know exactly what that piece of page code was going to do. At the same time, other pages may be attempting to access and use that page. However, in order to use it properly, the calling page typically should understand how that other page code was authored and what must be done to properly access the page.
The problem with the ad hoc placement of components and files for implementing the application is further compounded by the possible ad hoc placement of data throughout the back-end system. For example, one set of developers may have created many different little applications. These applications each do a certain amount of processing on data within the back-end systems of businesses or enterprises established by a completely different group of developers. It may result that a particular piece of data needed to perform some of the processing could possibly be placed in any number of databases within the back-end systems. This ad hoc placement of necessary data generally makes it very, very difficult for users to access and view a new Website, or for Web application developers to view the back-end of a Website to determine how to design an application that can efficiently access and make use of the back-end systems.
Another problem began to emerge with the development of new client-types. In the beginning, most of the clients accessing Websites were typically Web browsers. With an almost singular client-type one of the only jobs for the application server was to generate HTML that may then be displayed to the user. However, as new clients emerged desiring connectivity to existing Websites, a new layer of work was created to facilitate supporting the new clients. Wireless application protocol (WAP) has been developed to facilitate Web access for wireless telephones using wireless mark-up language (WML). Similarly-scaled protocols facilitate connections by personal digital assistants (PDAs), such as PALM, INC.'s PALM PILOT™ PDAs. In addition to the new clients used by new devices, new client applications were developed for automating Internet access. Proxies, agents, search-bots, robots, spiders, and the like are generally programs that automatically perform searches of or execute components on designated Websites or databases. Instead of accessing the Website using a Web browser, these automated applications use different protocols to directly search the back-end systems and/or access application or component capabilities. For example, purchasing robots may be scripted/programmed by a user to search the Internet for the best price on a particular item, and then to purchase that item on the best Website.
Furthermore, new technologies are evolving for client-side applications in which data is served by the remote Web or application server to the client for processing and/or executing on the client. One such technology streams data from a remote location to the client to be displayed on a local player or interface. MACROMEDIA'S FLASH™ is being used in development of rich-client applications which, instead of requiring HTML rendered by the application server, generally uses data and FLASH™ operations from the application-side to be played on the client-side FLASH™ player. Application developers creating and/or adapting these dynamic applications across multiple client types must expend a large amount of time to rework and rebuild the applications to be able to support the new clients.
Two methods are in general use for allowing distributed applications to communicate with various technologies. In the first method, a customer must typically re-engineer an application every time it desires to support a new client. For instance, if an application is written to support access from browsers via hypertext transfer protocol (HTTP), but later is desired to support access to the same business logic via a mobile phone and other business systems, the application developer would generally have to engineer an entirely new set of entry points to be used by the mobile phone and another set for the business systems.
The second generally used method includes a customer developing its application to leverage access via a broker-based or proxy-type technology. The broker or proxy generally is designed for a single back-end contact protocol. Therefore, the application typically only needs to understand how to connect to the broker through the single back-end protocol. Each broker then may have a specifically designed external interface as well. For example, one broker may be able to provide external access by an HTTP client, while another broker provides external access by a mobile phone. The business logic of the application is able to leverage a single back-end protocol to access both brokers. Therefore, the different clients access the same business logic using a proxy-type system.
Examples of broker-based technology includes common object request broker architecture (CORBA), which uses interface definition language (IDL) for exposing metadata about the interface to the application; distributed component object model (DCOM), which uses a proprietary method from MICROSOFT CORPORATION to describe its metadata; and Web services, which use web services description language (WSDL) to expose its metadata. In the case of Web services, WSDL comprises extensible markup language (XML) to describe the metadata, but WSDL is typically not written directly by a developer. Instead, it is almost always generated by the broker technology. WSDL only describes a component's interface. It does not provide any specific implementation of the interface. Therefore, application developers typically code programs in full-blown object oriented programming languages, such as JAVA™, C++, or C# to provide the actual functionality for the Web service. The “reflection” technology, in such object oriented languages, allows the broker technologies to examine the objects' written by the programmers and then extract the metadata.
The problems with each of these methods is the complexity required to provide multi-format access to a customer's application. Either experienced programmers are needed to re-engineer the application every time a new access protocol is desired, or they must re-engineer or develop particular brokers or proxies for each new protocol.